[Platform] Introduce asynchronous jobs and move MiniMax polling out of the result converter - #2408

…r-hertel)

This PR was squashed before being merged into the main branch.

Discussion
----------

[Platform] Fix asynchronous job follow-ups from #2408

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | no
| Docs?         | yes
| Issues        | -
| License       | MIT

Follow-ups on #2408, found while reviewing it after the merge. Ships with #2408 in 0.14, so nothing
released changes and no `UPGRADE.md` entry is added — the existing ones are corrected to describe
what will actually ship.

* MiniMax answers a healthy poll with `status_code: 0` **and** `status_msg: "success"`, which was read as a failure message, so every running job carried `"success"` in `JobStatus::getError()`. Verified against the live API.
* A query MiniMax rejects with HTTP 200 carries the reason in `base_resp` and no state at all, which mapped to `UNKNOWN` (non-terminal) — the runner then polled it for the whole budget, up to ten minutes for a video handle. It now ends the job, while a state merely spelled in a way the bridge does not know stays non-terminal.
* `JobRunner` turned the budget into a poll count, so the requests themselves were free: `maxDuration: 600` meant 600 requests plus 599 sleeps. It now waits against a clock deadline.
* `JobClientInterface::supports()` had no caller anywhere; the runner asks before polling.
* `MiniMaxResultConverter` held a `MiniMaxJobClient` only to read a name off it, building one with `new EventSourceHttpClient()` and an empty API key when given none. It takes the name; `MiniMaxJobClient::createHandle()` and its provider argument go.
* Docs: the autowiring example used `$minimaxJobClient`, but the registered alias is `JobClientInterface $minimax`, so it never autowired — checked by compiling a container. Also a nullable `getProvider()` passed to `ContainerInterface::get()`, an unassigned `$id`, and examples using `createProvider()` where every other MiniMax example uses `createPlatform()`.
* The 0.14 rebase had replaced the `CHANGELOG` heading underline with `==` in two files; `examples/minimax/.gitignore` missed the artifacts the new examples write.

All nine MiniMax examples were run against the live API: async speech (9s, real mp3 out of the tar),
video generation (83s, 792 KB mp4) and the resume flow across four processes from the stored handle.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Commits
-------

e7af258 [Platform] Fix asynchronous job follow-ups from #2408

An alternative to symfony#1802: batch is not its own stack of BatchJob/BatchManager/
BatchStatus classes, but the asynchronous job that symfony#2408 introduced - a batch is
a job that happens to carry many requests.

Submitting goes through `Platform::invoke()` with several inputs instead of one,
keyed by the identifier each result is reported back under, and returns a plain
`JobHandle`:

    $handle = $platform->invoke('gpt-4o-mini', [
        'capital-fr' => new MessageBag(Message::ofUser('What is the capital of France?')),
        'capital-de' => new MessageBag(Message::ofUser('What is the capital of Germany?')),
    ], ['batch' => true])->asJob();

Resolving it is `JobClientInterface`, so storing the handle, polling from a
worker, `JobRunner`, the exceptions and the bundle wiring all come for free.

A finished batch converts into a `BatchResult` of `BatchItem`s, read from the
download as they are iterated. A successful item carries the ordinary result the
request would have produced synchronously, built by the bridge's own converter,
so tool calls and structured output survive the detour.

An alternative to symfony#1802: batch is not its own stack of BatchJob/BatchManager/
BatchStatus classes, but the asynchronous job that symfony#2408 introduced - a batch is
a job that happens to carry many requests.

Submitting goes through `Platform::invoke()` with several inputs instead of one,
keyed by the identifier each result is reported back under, and returns a plain
`JobHandle`:

    $handle = $platform->invoke('gpt-4o-mini', [
        'capital-fr' => new MessageBag(Message::ofUser('What is the capital of France?')),
        'capital-de' => new MessageBag(Message::ofUser('What is the capital of Germany?')),
    ], ['batch' => true])->asJob();

Resolving it is `JobClientInterface`, so storing the handle, polling from a
worker, `JobRunner`, the exceptions and the bundle wiring all come for free.

A finished batch converts into a `BatchResult` of `BatchItem`s, read from the
download as they are iterated. A successful item carries the ordinary result the
request would have produced synchronously, built by the bridge's own converter,
so tool calls and structured output survive the detour.

… (chr-hertel)

This PR was merged into the main branch.

Discussion
----------

[Platform] Convert polling bridges to asynchronous jobs

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| Docs?         | yes
| Issues        | -
| License       | MIT

Follow-up to #2408: the Higgsfield, Venice and Replicate bridges solved async work with their own
polling loops. They now return a `JobResult` carrying a `JobHandle`, resolved through a per-bridge
`JobClientInterface` — same shape as MiniMax.

- `HiggsfieldJobClient`, `VeniceJobClient`, `ReplicateJobClient` + `Factory::createJobClient()`
- ai-bundle registers `ai.platform.job_client.higgsfield` / `.venice` (tagged + autowired)
- Removed the now-dead `clock` / `pollingInterval` / `max_polling_attempts` / `polling_interval_seconds` args

While at it, `JobHandle` gained `getPollInterval()` next to `getMaxDuration()` — how often a job is
worth asking about is the bridge's knowledge just like how long it runs — and `JobRunner` gained a
`maxPolls` ceiling, which is the caller's (a rate limit, an API bill). Both resolve
`call > runner > handle > default`.

**Needs the `BC Break` label** — Replicate is released, and its invocations no longer return a
`TextResult` directly (`UPGRADE.md` entry included). Higgsfield and Venice were both added in the
unreleased 0.14, so they get no upgrade entry.

Cassettes were extended by hand rather than re-recorded (no API keys): `getStatus()` + `getResult()`
means one extra poll of the finished job, so each gained a duplicate of its final terminal-status
interaction — the same shape MiniMax's committed cassette already has.

Also passes the examples' clock to the MiniMax job runners, which were sleeping for real on replay:
`minimax/text-to-video.php` went from 52s to 0.06s, and the whole replay suite from 67s to 16s.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Commits
-------

af06ee0 [Platform] Convert polling bridges to asynchronous jobs

An alternative to symfony#1802: batch is not its own stack of BatchJob/BatchManager/
BatchStatus classes, but the asynchronous job that symfony#2408 introduced - a batch is
a job that happens to carry many requests.

Submitting goes through `Platform::invoke()` with several inputs instead of one,
keyed by the identifier each result is reported back under, and returns a plain
`JobHandle`:

    $handle = $platform->invoke('gpt-4o-mini', [
        'capital-fr' => new MessageBag(Message::ofUser('What is the capital of France?')),
        'capital-de' => new MessageBag(Message::ofUser('What is the capital of Germany?')),
    ], ['batch' => true])->asJob();

Resolving it is `JobClientInterface`, so storing the handle, polling from a
worker, `JobRunner`, the exceptions and the bundle wiring all come for free.

A finished batch converts into a `BatchResult` of `BatchItem`s, read from the
download as they are iterated. A successful item carries the ordinary result the
request would have produced synchronously, built by the bridge's own converter,
so tool calls and structured output survive the detour.

…nous jobs (chr-hertel)

This PR was squashed before being merged into the main branch.

Discussion
----------

[Platform] Add OpenAI batch requests on top of asynchronous jobs

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| Docs?         | yes
| Issues        | Fix #1776
| License       | MIT

An alternative to #1802: now that #2408 landed asynchronous jobs, a batch is just a job that carries many requests — no `BatchJob`/`BatchManager`/`BatchStatus` stack needed.

```php
$handle = $platform->invoke('gpt-4o-mini', [
    'capital-fr' => new MessageBag(Message::ofUser('What is the capital of France?')),
    'capital-de' => new MessageBag(Message::ofUser('What is the capital of Germany?')),
], ['batch' => true])->asJob();

// later, in a worker, from the stored handle
$jobClient = OpenAiFactory::createJobClient($apiKey);

foreach ($jobClient->getResult($handle)->getContent() as $item) {
    echo $item->getId().': '.($item->isSuccess() ? $item->getResult()->getContent() : $item->getError());
}
```

* Storing the handle, polling, `JobRunner`, the exceptions and the bundle wiring all come from #2408 unchanged
* `['batch' => true]` is handled by `Gpt\ModelClient` and delegated to `Batch\BatchClient`, like `MiniMaxClient` routes on `async` — no routing in `Provider`
* A finished batch converts into a `Result\BatchResult` of `Result\BatchItem`s, read from the download as they are iterated; a successful item carries the ordinary result the request would have produced synchronously, built by the bridge's own converter (tool calls, structured output, finish reasons included)
* An item without a result states *why* through a `Result\BatchItemCase` — `ERRORED` has to be fixed, `CANCELED`/`EXPIRED` were never sent and can simply be resubmitted — with the provider's own wording kept on `getRaw()`, the same split as `FinishReason` and `JobStatus`
* A cancelled or expired batch still hands out what it finished, since fetching keys on the result file rather than on `completed`
* `Batch\JobClient` adds `getRequestCounts()` and `cancel()` — on the bridge, not on `JobClientInterface`

### Does the result shape generalize?

Checked the two obvious next bridges before settling it, since `BatchResult`/`BatchItem` sit in the Platform:

* **Mistral** — the same envelope to the letter. Its SDK parses `custom_id` / `response.body` / `error` with `status_code >= 400` as the failure test, which is `Batch\JobClient::toItem()` line for line, and documents that envelope as invariant across endpoints. Statuses map onto `JobStateCase` without a gap.
* **Anthropic** — submits inline rather than as a file (submit side only, per bridge) and reports four per-request outcomes: `succeeded`, `errored`, `canceled`, `expired`. That is what `BatchItemCase` is for. Its batch-level status is only `in_progress`/`canceling`/`ended`, and a cancelled batch also ends as `ended` with partial results — so keying result-fetching on the file rather than on a success status is not just convenient here, it is the only thing that works there.

Request counts differ per provider (`{total, completed, failed}` vs `{processing, succeeded, errored, canceled, expired}` vs `{total, succeeded, failed}`), which is why `getRequestCounts()` stays on the bridge.

### Open point

No `Capability::BATCH`. OpenAI gates batching per endpoint, not per model, and the option is handled by the endpoint's own model client, so the gate is structural and there is no list to keep up to date — an ineligible model is rejected by the API. Happy to add the capability instead if you prefer the pre-flight check.

Scoped out for follow-ups: the Anthropic and Mistral bridges, and batched embeddings (same `BatchClient`, different endpoint).

Commits
-------

5e61785 [Platform] Add OpenAI batch requests on top of asynchronous jobs